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STUDY  TITLE 


THE  CRITICAL  STEP:  THE  INITIAL  PROGRAM  MANAGEMENT  PLAN 


STUDY  PROJECT  GOALS: 

lb  examine  the  hypothesis  that  the  initial  Program  Management  Plan  (PMP)  is  the 
most  critical  management  step  in  a development  and  acquisition  program;  to 
examine  the  development  process  of  the  initial  PMP  and  identify  factors  which 
de-op timLze  the  f emulation  process. 


3 STUDY  REPORT  ABSTRACT: 

starting  with  the  hypothesis  that  the  initial  project  plan,  to  a great  extent, 
determines  the  ultimate  outoorre  of  the  project  in  terms  of  schedules,  costs  and 
technical  performance,  the  author  discusses  the  current  management  environment 
which  prevails  today  in  the  military  departments  and  the  Secretary  of  Defense 
Office.  Against  tills  background  the  discussion  continues  as  it  develops  a 
theoretical  model  for  the  development  of  the  initial  PMP.  This  model  proposes 
that  the  two  functions,  planning  and  controlling,  each  consist  of  three  elements; 
assumptions,  planning,  programming  and  scheduling,  costing,  resource  allocations, 
respectively.  The  hierarchical  dependencies  of  these  elements  are  discussed  in 
detail.  Through  the  technique  of  program  manager  interviews,  the  author  iden- 
tifies eight  factors  which  tend  to  de-eptimize  the  process:  inside-out  approach, 
preconceived  solution,  h’ly  Plan*  syndrome,  inadequate  threat  definition,  inad- 
equate technical  base,  inadequate  staff  support,  time  pressure,  wrong  priority. 
Each  factor  is  discussed  in  detail . Finally,  six  actions  are  reocirmanded:  edu- 
cation of  the  PM  on  the  significance  of  this  document  , Headquarters  must  not  issue 
schedules  and  budgets  prematurely,  higher  authorities  must  stop  micro  managing 
the  prograta  based  upon  detailed  FMPs,  PM  must  insist  adequate  time,  resources 
and  priority  are  available,  the  PMP  format  should  be  at  least  three  volumes 
which  segregate  fiscal  data  frcm  general  technical  plans.  PM  must  challenge  the 
threat  definition  prior  to  issuing  the  PMP. a /"pV-- 
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EXECUTIVE  SUMAJOT 


The  author  expresses  a hypothesis,  by  Peter  C.  Sandretto,  that  the 
initial  project  plan,  to  a great  extent,  determines  the  outcome  of  a 
project  in  terms  of  time,  costs,  and  technical  performance.  This  report, 
develops  the  background  and  history  of  the  Military  Program  Manager  phi- 
losophy and  its  relationship  to  the  Department  of  Defense  Programming, 
Planning  and  Budgeting  System. 

In  the  second  section  of  the  report  a model  for  the  formulation  of 
the  initial  Program  Management  Plan  is  developed.  In  this  model  two  func- 
tions are  proposed,  each  having  three  elements;  assumptions,  planning  and 
programming  constitute  the  planning  function;  scheduling,  costing  and 
resource  allocation  constitute  the  control  function.  The  interrelation- 
ships of  these  elements  in  the  formulation  process  is  discussed.  The 
model  discussion  concludes  with  a proposal  and  rationale  for  publishing  the 
Program  Management  Plan  in  three  volumes  and  discusses  the  relationship 
of  the  Program  Management  Plan  to  a variety  of  other  documents  required 
in  the  weapon  systems  acquisition  process. 

In  the  last  major  section,  the  author  discusses  eight  factors  which 
tend  to  de-optimize  the  formulation  process  and  proposes  six  specific 
changes  which,  if  implemented,  could  significantly  inprove  the  quality  of 
the  intial  Program  Management  Plan. 
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INTRODUCTION 


During  the  fiscal  year  1977,  the  Department  of  Defense  (DOD)  will 
spend  eleven  billion  dollars  in  the  weapon  systems  development  and  engi- 
neering process  (2  :256)  Putting  it  another  way,  approximately  10$  of 
each  taxpayer's  defense  dollar  will  be  spent  this  year  in  the  arena  of  aims 
development  and  engineering,  it  is  of  little  wonder  then  that  the  manage- 
ment of  these  programs  continues  to  receive  increased  surveillance  by 
Congress  and  the  highest  levels  of  DOD  management.  This  increased  interest 
is  continually  proded  by  sensational  accusations  of  "gross  mismanagement  by 
DOD  officials"  in  newspapers  and  periodicals  as  reporters  perform  their 
role  of  public  watch  dogs.  Unfortunately,  subsequent  investigations  far 
too  often  reveal  more  than  just  a trace  of  truth  to  these  accusations. 

The  challenge  is  clear.  Better  management  of  weapon  systems  acqui- 
sition is  an  absolute  requirement,  not  just  a goal,  if  the  United  States 
desires  to  remain  militarily  strong  enough  to  ensure  the  freedom  we  have 
enjoyed  over  the  past  two  centuries. 

Peter  C.  Sandretto,  in  his  book,  "The  Economic  Management  of  Research 
end  Engineering,"  proposes  that 

"After  all  has  been  said  and  done  about  systems  to 

*This  notation  will  be  used  throughout  the  report  for  sources  of  quota- 
tions and  major  references.  The  first  number  is  the  source  listed  in  the 
bibliography.  The  second  number  is  the  page  in  the  reference. 
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control  engineering  costs  and  performance  after 
the  decision  is  made  to  embark  on  a project/  it 
is  the  project  plan,  prepared  before  starting  the 
work/  that  determines  to  a major  extent  the  out- 
ooroe  of  a project  in  terms  of  time,  costs  and 
technical  performance. 

Almost  universally,  there  has  been  a lack  of 
realization  that  once  a project  plan  is  accepted, 
the  cLe  is  cast.  Further  action  can  help  to  steer 
the  course  of  the  project  and  possible  oonduct  a 
rescue  from  diaster,  but  the  road  sign  to  the 
disaster  point  was  erected  when  the  project  plan 
was  written  (10:68)." 


A brief  survey  of  Program  Management  Plans  supports  Sandretto's 
hypothesis.  The  opinions  of  todays  program  managers  regarding  the  ne- 
cessity and  utility  of  this  critical  document,  the  Program  Management  Plan 

(PMP) , varies  throughout  the  continuum  of  "never  use  it"  to  "it's  try 

* 

program  Bible  - — absolutely  indispendable . " (9) 

Virile  it  is  obvious  that  the  development  of  a perfect  PMP  will  not 
guarantee  that  the  program  will  be  successful,  it  is  reasonable  to  con- 
clude that  a poor,  incomplete  PMP  will  guarantee  unnecessary  difficulties  ' 
in  successful  program  oarpletion.  Why  then,  are  so  many  PMPs  "bad?"  It 
is  the  objective  of  this  paper  to  examine  that  question.  The  approach  is 
straightforward  - first,  look  at  the  historical  development  of  the  program 
. manager  (PM)  concept  in  DOD  in  order  to  establish  the  management  environ- 

* ment;  second,  examine  the  PMP  concept;  third,  discuss  seme  of  the  major 

factors  vrtuich  tend  too  de-optimize  the  PMP  development  process;  finally, 
offer  sane  suggestions  for  improving  the  process. 
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BACKGROUND 

Bie  concept  of  "Program  Management"  did  not  siirply  evolve  in  the  DOD. 
Quite  to  the  contrary,  it  was  forcibly  imposed  upon  the  very  highly  struc- 
tured, bureaucratic  military  organization  (9  :62) . By  their  very  nature, 
of  their  mission  or  objective,  the  Departments  of  the  Army,  Navy 
and  Air  Force  must  be  bureaucratic  organizations.  Yet,  the  weapons  devel- 
opment and  acquisition  process  does  not  lend  itself  to  totally  bureaucratic 
procedures.  As  we  shall  see  later,  this  imposed  program  management  phil- 
osophy can  be,  but  does  not  have  to  be,  self-defeating  in  the  PMP  devel- 
opment process.  What  then  is  this  environment  and  where  did  it  came 
from? 

In  1961,  Mr.  Robert  S.  McNamara,  occupying  the  Office  of  Secretary  of 
Defense  (OSD) , elected  to  make  a bold  move  and  attenpt  to  structure  the 
planning  and  budgeting  system  of  the  DOD  in  accordance  with  good  business 
practices.  Fran  his  point  of  view,  there  were  sufficient  similarities 
between  the  DOD  and  a large  aomplex  corporation  to  convince  him  that  the 
DOD  could  and  should  have  a continuous,  interrelated  planning  and  budget- 
ing system  which  would  provide  long  term  (five  year)  visibility  to  the 
DOD  operation.  Such  a set  of  docunents  would  provide  the  OSD  and  the 
rvxvjrf^s  a yardstick  for  measuring  successes  and  failures.  Furthermore, 
if  he  could  inplorent  such  a system,  both  OSD  and  the  Congress  would  have 
a better  vehicle  for  making  long  range  strategic  decisions. 

It  was  this  pr anise  then  that  resulted  in  the  Programming,  Planning 
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end  Budgeting  System  (PPBS)  which  the  DOD  uses  today.  The  PPBS  concept 
is  quite  logical.  In  simplistic  form,  it  starts  with  a plan  which  defines 
military  deficiencies,  with  supporting  data,  and  offers  severed,  altema- 
tives  for  meeting  these  deficiencies  or  objectives.  After  review  and 

• . 

acceptance  of  the  plan  in  principle,  the  plan  is  programed.  During  the 
; * programing  process,  the  constraints  of  event  sequencing  and  time  schedules 

are  imposed  upon  the  alternatives , and  preliminary  alternative  selections 
are  made.  The  surviving  alternatives  are  then  prioritized  and  assigned  a 
level  of  criticality  with  respect  to  how  soon  each  alternative  must  be 
implemented.  This  "Program  Plan"  is  then  subjected  to  the  final  critical 
test  - affordability.  Anticipated  costs  are  assigned  to  each  alternative 
i which  survived  the  programming  process  and  final  selections  are  made. 

These  items  then  provide  the  basis  for  the  forthcoming  Department  of  De- 
fense submissions  for  the  President's  Budget  (7:1). 


i 
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't 

t 
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Once  an  item  is  included  in  the  President's  Budget,  the  assumption 
is  made  that  the  requested  items  will  be  approved  in  the  final  Congressional 
Authorization  and  Appropriations  Acts  and  the  PPBS  process  starts  over 
again,  using  the  budgeted  information  as  che  base.  Thus,  in  its  simplistic 
form,  the  PPBS  provides  a mechanism  for  an  iterative  management  informa- 
tion system  with  which  the  OSD  and  the  Cbngress  attempt  to  manage  the 
complex  Department  of  Defense. 

Following  the  philosophy  of  Mr.  McNamara,  in  May  of  1964,  Mr.  Cyrus 
Vhnce,  Deputy  Secretary  of  Defense,  issued  Department  of  Defense  Directive 
(DCCD)  5010.14,  Sys ten/Project  Management,  which  directed  the  Military 
Departments  to  establish  centralized  management  authorities,  supported  by 
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functioned  elements,  to  develop  and  acquire  selected  major  weapon  systems 
(6:2) . With  this  DODC,  the  concept  of  Program  Management  was  applied 
throughout  the  Department  of  Defense. 

By  the  end  of  the  decade,  the  PPBS  and  Program  Management  procedures 
became  a fact  of  life  for  the  OSD  and  the  DOD.  As  a result  of  this  new 
visibility  at  the  OSD  and  congressional  level,  it  became  obvious  that 
there  were  still  serious  problems  associated  with  the  way  the  DOD  and 
Departments  of  the  Amy,  Navy  and  Air  Force  managed  the  development  and 
acquisition  of  their  weapons  systems.  After  a comprehensive  evaluation, 
Mr.  David  Packard,  the  Deputy  Secretary  of  Defense,  issued  DODD  5000.1, 
dated  13  July  1971,  and  redefined  the  OSD  role  in  the  program  management 
process  (4  :2) . A review  oouncil , the  Defense  System  Acquisition  Review 
Council  (DSARC) , headed  by  the  Deputy  Director  of  Research  and  Development 
(DDR&D)  was  proposed  as  the  OS)  controlling  body  to  review  and  recommend 
initiation  and  termination  of  individual  service  programs  (5:2). 

Thus,  in  a single  decade,  considerably  less  than  one  generation  of 
military  personnel,  the  services  had  twice  been  directed  to  drastically 
change  the  traditional  methods  of  operation  and  control.  Bach  of  these 
actions  made  the  individual  military  departments  less  independent,  less 
able  to  determine  their  cwn  destiny  and  subject  to  more  and  more  external 
scrutiny  and  control.  Confusion,  resistance  and  mistakes  were  inevitable 
as  the  "new"  organizations  developed  and  matured.  Unfortunately,  the 
effects  of  such  drastic  changes  are  not  yet  universally  recognized  nor 
accepted  with  tolerance  and  understanding.  Thus,  criticism  and  accusa- 
tions of  "inoorpebency"  are  just  as  inevitable  as  the  mistakes  which  will 
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be  made  throughout  the  maturing  process. 

Ihe  PM  of  today  finds  himself  involved  in  a net/  organization, 
drastically  different  from  the  one  he  was  trained  and  educated  in,  subject 
to  a level  of  review  and  visibility  heretofore  unknown  to  him.  At  the 
same  time,  this  military  organization  is  undergoing  severe  interned 
* turmoil  as  it  attenpts  to  rapidly  change  traditions,  methodologies  and 

ingrained  philosophies.  The  trend  to  decentralize  major  aspects  of  OSD 
control  continues  to  add  to  the  turmoil  with  a recent  rewrite  of  DON) 
5000.1  (3:2).  The  thrust  of  this  new  DOCK)  5000.1  is  to  allocate  more 
inplementation  review  and  aontrol  authority  back  into  the  individual 
Servioe  organizations  and  to  strengthen  the  position  of  individual  PMs. 
Within  this  environment  then,  let's  examine  the  question  - "Why  are  the 

K 2 

PMPs  so  bad?" 
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PMP  PORMULATICN 

Before  we  can  analyze  the  PMP  and  identify  the  factors  which  address 
the  question  of  why  sene  PMP's  are  bad,  it  is  critical  to  understand  the 
functions  which  make  up  the  PMP  and  to  understand  the  elements  of  each 
function.  Furthermore,  it  is  just  as  essential  to  have  a full  under- 
standing of  the  dependency  hierarchy  of  these  functional  elements  and 
their  various  interrelationships.  In  this  section,  the  functions  and 
elements  will  be  defined  and  discussed,  and  the  utility  of  the  PMP 
surveyed. 

DEFINITIONS 

In  the  Merriam-Webster  Dictionary,  a "plan"  is  defined  as  "a  method 
for  aooonplishing  something."  This  definition  is  far  too  broad  for  our 
use,  but  applying  the  same  principle,  a management  plan  can  be  defined  as 
the  proposed  management  methodology  for  attaining  a given  end  objective. 
Assizning  that  a management  plan  is  developed  under  circumstances  where 
the  starting  base  is  well  established  and  fully  understood,  the  end 
objective  is  firmly  defined  with  no  chance  for  change,  and  experience  has 
identified  the  best  way  to  get  there,  the  plan  is  very  straightforward. 
Little  difficulty  is  encountered  in  either  writing  it  down  or  executing 
it  successfully.  Since  none  of  these  conditions  are  likely  to  exist  at 
the  time  an  initial  PMP  is  required  for  the  acquisition  of  a new  weapon 
system,  even  this  definition  appears  inadequate.  In  this  specific  context 
then,  it  is  more  appropriate  to  define  the  PMP  as  the  proposed  management 
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methodology,  with  proposed  contingency  alternatives  for  attaining  an 
assured  end  objective. 

The  PMP  development  process  can  be  divided  into  two  functions; 
program  planning  and  program  controlling.  The  program  planning  function 
consists  of  three  elements  - assumptions,  planning  and  programming,  like- 
wise, the  controlling  function  can  be  divided  into  three  elements  - 
scheduling,  costing  and  resource  allocation.  For  purposes  of  this 
discussion,  the  following  definitions  will  be  used  for  these  six  elements, 

. assumptions  - uncertain  or  nonvalidated  information  which 
form  the  basis  of  subsequent  action. 

. planning  - identifying  all  actions  required  to  proceed 
from  where  you  are  to  where  you  wish  to  be. 

. programming  - ordering  all  required  actions  into  a logical 
sequenoe. 

. costing  - cost  of  completing  any  given  action  or  series 
of  actions. 

. resource 

allocation  - allocating  money  and  manpower  to  an  action  or 
series  of  actions  in  order  to  implement  that 
action  or  series  of  actions. 

. scheduling  - the  assignment  of  quantitative  time  values 
to  an  action  or  series  of  actions. 

THE  PLMNING  FUNCTION 

Using  these  definitions,  we  are  ready  to  examine  the  program  planning 
function  of  the  PMP  development  process.  We  will  limit  this  discussion 
to  the  development  of  the  initial  PMP  and  will  not  include  the  process  of 
qpdating  a PMP  which  has  already  been  developed.  Although  there  are  close 
similarities  to  'he  updating  process  and  the  initial  process,  the 
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the  user  of  the  final  responsibility  for  the  development  of  an  end  pro- 
duct, which  could  be  useless  “hen  built  to  meet  the  user's  stated  re- 
quirements. 

How  then  should  the  PM  resolve  this  critical  issue  of  defining  his 
end  abjective?  Stated  simply,  the  new  PM  must  develop  his  set  of  assump- 
tions and  define  his  perception  of  the  threat.  If  he  is  knowledgeable 
and  persistant,  a representative  of  the  potential  user  will  finally  agree 
that  his  assumptions  and  perception  represent  the  best  estimate  of  the 
forecast  requirement  and  will  coordinate  on  the  statement  of  requirement 
document.  What  this  says  is  that  the  user  representative  agrees  that  the 
PM's  assumptions  and  threat  definition  is  as  good  as  the  user  aould  define. 
With  the  signing  of  this  memorandum  of  agreement  between  the  PM  and  a 
representative  of  the  potential  using  agency,  the  PM  accepts  full  respon- 
sibility for  making  sure  that  the  end  product  he  initially  intends  to 
develop  will  meet  this  assuned  military  threat  at  some  future  date,  even 
though  the  threat  which  materializes  may  only  vaguely  resemble  the  initial 
assuned  threat. 

The  next  area  which  usually  requires  the  PM  to  make  a set  of  assump- 
tions is  defining  the  technical  base  available  to  him  at  the  start  of  the 
program.  Unlike  the  end  objective,  here,  the  PM  is  far  more  likely  to 
assume  a more  mature  technology  base  than  actually  exists.  In  part,  this 
is  caused  by  the  total  absence  of  any  individual  organization  which  can 
objectively  give  the  PM  a clear,  factual  statonent  of  the  technology  base 
available  to  him.  Therefore,  in  order  to  obtain  this  information,  the 


PM  must  oomrunicate  directly  with  the  development  scientists  and  engineers 
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who,  by  the  very  nature  of  their  professions,  are  optimists.  Thus,  the 
PM  always  starts  with  am  optimistic  evaluation.  Once  again,  the  PM  is 
faced  with  the  task  of  establishing  his  assumptions  regarding  the  technical 
base,  and  once  again,  the  development  organizations  are  willing  to  coor- 
dinate with  the  PM's  assumptions,  as  long  as  they  are  reasonably  optimistic. 

Although  many  other  assumptions  are  made  by  the  PM  throughout  the 
development  of  the  initial  PMP,  these  two  provide  the  very  basis  for  the 
plan,  ie,  the  starting  point  and  the  end  point.  By  understanding  that 
both  of  these  points  are  heavily  based  upon  assumptions,  the  PM  should 
have  an  insight  as  to  why  and  how  this  initial  PMP  has  such  a high  poten- 
tial far  being  "bad."  However,  just  because  the  PMP  mast  be  based  upon 
such  assuiptions  does  not  mean  that  the  program  is  destined  to  fail. 

Planning 

Gkioe  the  technical  base  and  threat  are  defined  and  agreed  to,  and 
the  general  type  of  weapon  system  defined,  the  major  planning  effort  can 
proceed.  The  objective  of  this  phase  is  to  start  with  the  assured  tech- 
nical base  and  identify  all  possible  actions  which  will  be  required  to 
develop  and  deploy  the  weapon  system  destined  to  negate  the  assumed 
threat.  Not  only  must  all  technical  problems  and  solution  actions  be 
identified,  but  all  possible  management  actions  and  alternatives  which 
could  be  utilized  need  to  be  identified.  Inadequate  attention  to  either 
portion  of  this  process  almost  guarantees  serious  difficulties,  if  not 
failure,  in  execution  of  the  plan. 


The  first  step  of  this  planning  process,  then,  is  to  identify  and 


list  all  of  the  technical  and  management  actions  which  will  need  to  be 
addressed.  Alternatives  should  be  identified  to  provide  for  the  even- 
tuality that  any  single  action  is  not  successful.  The  end  product  of  this 

phase  is  a list  of  all  reasonable  actions,  both  technical  and  managerial, 
i . 

I which  oust  be  accomplished  in  order  to  meet  the  end  objective,  with 

i ' alternatives  for  each  action.  In  this  process,  it  is  ocrmon  to  find  that 

e 

there  may  be  seme  actions  for  which  there  are  no  reasonable  alternative 
actions  available . Clearly  then,  these  items  become  critical  go,  no  go 
decision  points  in  the  program  and  require  special  attention  from  this 
point  on. 

; * 

The  nature  of  this  list  should  be  nearly  exhaustive.  It  should 
include  all  anticipated  documentation  efforts  which  will  be  required 
throughout  the  program,  discrete  technical  efforts,  testing,  safety 
programs,  deployment  transition  efforts,  supporting  research  and  devel- 
opment efforts,  etc. , without  regard  to  how  it  will  be  sequenced,  funded 
or  executed.  By  the  time  this  planning  element  of  the  PMP  development  is 
acnpleted,  the  scope  of  the  effort  as  well  as  identification  of  all  the 
required  actions  have  been  considered  and  written  down.  This  step  is  the 
most  critical  part  of  the  PMP  development  process,  for  once  the  PMP  is 
developed  and  published  there  will  be  no  time  to  repeat  this  process.  It 
is  now  or  never! 

Now  that  a oonprehensive  list  of  action  items  has  been  developed,  the 
second  part  of  the  planning  process  is  fairly  straightforward  - identify- 
ing who  could  perform  each  of  the  action  items.  One  way  to  acocnplish 
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this  is  to  develop  a matrix  structure  with  "what"  on  one  axis  and  "who"  on 
the  other  axis.  By  "who,"  it  is  intended  that  all  proposed  agencies  which 
could  potentially  be  involved  with  the  program  are  identified  for  initial 
consideration.  This  should  include  contractors,  either  generically  or  ty 
none,  government  agencies,  the  program  management  office  itself,  etc. 

This  list  identifies  all  possible  members  of  the  program  team.  Once  the 
"whats"  and  "whos"  are  identified  on  the  two  axis  of  the  matrix,  the 
filling  in  of  the  matrix  is  quite  straightforward  and  proceeds  rapidly. 

The  critical  nature  of  this  planning  phase  cannot  be  over  emphasized, 
for  the  thoroughness  of  this  final  matrix  provides  the  total  basis  for 
establishing  a viable  PMP  which  will  maximize  the  chances  of  successfully 
completing  the  program  and  reaching  the  end  objective.  It  is  here  that 
most  poorly  conceived  and  written  plans  have  failed.  Numerous  opportu- 
nities exist  for  failing  at  this  time.  For  example,  a preconceived  notion 
of  how  and  what  almost  always  eliminates  consideration  of  alternatives. 

The  lade  of  alternatives  results  in  failure  to  recognize  critical  items 
which  require  early  and  constant  attention  and  usually  results  in  failure 
to  identify  better  ways  of  accomplishing  the  objective. 

The  planning  element  is  clearly  the  most  critical  and  time  consuming 
part  of  the  PM*  development  process,  for  it  creates  the  very  basis  for 
all  subsequent  decisions.  The  planning  element,  consists  of  two  discrete 
operations;  identification  and  listing  of  all  technical  and  managerial 
actions,  and  identification  of  all  potential  program  team  members  who 
could  perform  each  item. 


Programing 

After  the  development  of  a complete  planning  matrix,  the  programing 
function  is  relatively  easy.  The  resorting  of  the  action  items  into  a 
sequential  format  is  normally  fairly  obvious  and  can  be  done  in  a short 
period  of  time.  Nonetheless,  this  process  requires  close  attention  since 
frequently  the  sequence  of  events  is  the  primary  factor  in  the  next  effort: 
development  of  the  control  tactics.  By  tactics  we  mean  the  tentative 
identification  of  who  can,  or  should,  do  which  efforts.  This  will  require 
considerable  attention.  It  is  here  that  the  first  business  strategy  is 
developed.  Questions  such  as:  a)  in-house  or  contractual?  b)  one  or 

more  agencies  in  competition  or  parallel  efforts?  c)  development  of 
alternatives?  etc.  need  to  be  answered  at  this  point  in  time.  By  the 
time  this  phase  of  the  program  concept  is  developed,  the  PM P architecture 
is  beginning  to  take  a recognizable  form  and  ready  for  the  PM  to  develop 
the  control  functions. 

THE  CONTROL  FUNCTION 

The  control  function  has  three  elements,  schedule,  costing  and 
reeouroo  allocation.  These  are  the  oily  three  elements  the  PM  can  directly 
control  - money,  manpower  and  time,  and  he  has  only  minimal  direct  con- 
trol of  the  time  element.  However,  scheduling  is  considered  a control 
function  since  time  is  a visible,  measurable  quantity. 

Schedule 

The  first  quantitative  values  required  are  time  estimates.  For  each 
action  item  a time  to  complete  estimate  must  be  developed  and  assigned. 
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Although  by  new  it  has  usually  been  decided  what  the  most  likely  approach 
will  be,  it  is  still  too  early  to  eliminate  the  options  and  contingency 
action  items.  All  of  these  must  be  objectively  evaluated  in  terms  of  the 
control  elements , money,  manpower  and  time.  Having  time  quantified  the 
programed  plan  (the  sequenced  plan)  the  format  may  be  changed  from  the 
matrix  into  a detailed  time  phased  network,  sinply  as  a ratter  of  con- 
venience and  clarity  of  presentation.  New  it  begins  to  look  very  much 
like  a decision  tree  skeleton,  and  is  becoming  a document  from  which  the 
PM  begins  to  do  sane  serious  abjective  evaluation  of  alternatives. 

Costing 

The  next  quantities  which  need  to  be  added  to  the  schedule  are 
aost  estimates.  Cost  estimating  undoubtedly  causes  the  PM  more  headaches 
than  any  other  element  of  the  PMP.  Most  of  that  is  generated  by  the 
emotional  prejudice  that  the  PM  associates  with  the  art  of  oost  estimating. 
Cn  the  other  hand,  he  has  no  choice  but  to  develop  cost  estimates  for  each 
and  every  action  item  identified  in  the  proposed  plan,  for  it  is  the  cost 
and  schedule  information  which  permits  him  to  further  select  among  the 
various  alternate  paths.  It  is  the  cost  and  schedule  estimates  which 
ultimately  provide  the  basis  for  proposing  the  business  strategy  and 
tactics. 

If  the  plan  has  been  developed  in  considerable  detail,  the  individ- 
ual action  items  are  well  defined  and  the  cost  estimates  should  be 
reasonably  accurate  far  those  actions  scheduled  for  completion  within  the 
first  year  or  two.  Beyond  tw  years,  the  cost  estimates  will  be  more  and 
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more  difficult  to  obtain.  As  a result  there  will  be  a tendency  to  assign 
wild  guesses  to  these  action  items.  In  today's  environment  of  pressure  to 
use  life  cycle  costs  and  unit  costs  as  decision  points  for  go,  no  go 
decisions,  these  always  tend  to  be  enormously  underestimated.  This  is 
another  sign  post  to  trouble  later  in  the  progran.  The  prudent  manager 
will  clearly  document  his  assumptions  and  data  sources  far  these  estimates, 
be  reasonably  pessimistic  and  assign  a probable  margin  of  error  to  these 
estimates.  It  is  almost  inpossible  to  overemphasize  the  importance  of 
this  initial  cost  estimating,  or  the  criticality  of  the  data  base  in  the 
PMP  front  which  it  was  derived.  Whether  the  PM  likes  it  or  not,  the  fact 
is  that  once  the  schedules  and  cost  estimates  developed  in  this  initial 
PIP  are  published,  these  values  become  firm  input  data  to  higher  head- 
quarters, DOD  and  Congressional  plans. 

Resource  Allocation 

Given  that  all  of  the  previously  described  steps  in  the  PMP  devel- 
opment process  have  been  carefully  and  successfully  ccnpleted,  the  next 
step  is  to  allocate  in-house,  other  government  agencies  or  contractual 
manpower  to  each  action  item.  Normally,  this  starts  with  the  structuring 
and  sizing  of  the  program  office  itself,  for  the  amount  of  support  re- 
quired from  other  government  agencies  and  contractors  is  dependent  upon 
how  self  aontained  the  program  management  office  is.  Again,  alternative 
sources  of  manpower  must  be  considered  and  contingency  actions  provided 
for  if  they  have  not  already  been  considered.  Nevertheless,  each  action 
item  is  now  considered  and  manpower  resource  allocations  identified  for 
each  one.  Whan  there  is  reasonable  doubt  that  government  manpower  will 
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be  available  for  a given  action,  that  action  item  should  have  contrac- 
tual manpower  assigned  to  it. 
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Following  the  allocation  of  manpower,  it  may  be  necessary  to  iterate 
sane  of  the  cost  estimating  of  selected  actions.  Since  this  is  almost 
unavoidable  at  the  very  early  time  of  the  program,  the  PM  must  exercise 
his  own  judgement  in  this  area.  Once  the  PM  is  satisfied  with  the  fined 
oost  estimates,  the  budgeting  process  is  quite  easy.  By  this  time,  a 
preferred  series  of  actions  are  visible  and  the  primary  budget  is  the 
simple  son  of  the  oost  estimates  for  each  action  scheduled  for  each  fiscal 
year.  Furthermore,  the  expected  oost  of  alternative  actions  are  available 
for  the  PM  to  negotiate  from  as  the  budgeting  process  continues.  The 
final  budget,  of  course,  should  include  reasonsable  contingency  funds  to 
aover  the  unexpected  events  which  will  occur  throughout  the  lifetime  of 
the  program. 


The  read  value  of  the  PMP  developed  in  this  way  becomes  quickly 
evident  as  the  PM  begins  to  defend  his  program  management  philosophy,  the 
manning  of  his  program  management  office,  the  submission  and  defense  of 
his  budget  requests  and  so  forth.  This  PMP  provides  most  of  the  input 
data  for  his  Advanced  Procurement  Plan  (APP)  and  Decision  Coordinating 
Paper  (DCP)  and  the  other  documents  which  are  all  required  early  in  the 
program.  But  most  iiqportantly,  the  FM  has  established  a firm  basis  of 
credibility  for  future  dealings  with  the  program  team  members  and 
higher  authorities  by  documenting  his  perception  of  the  problem  and  how 
he  plans  to  solve  it. 
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PMP  POFMAT 


One  of  the  authorities  delegated  to  the  PM  is  the  authority  to 
decide  the  format  of  his  program  PMP.  Most  PMP  documents  combine  both 
the  planning  function  data  and  the  control  function  data  into  a single 
volune.  The  net  result  of  this  is  that  it  restricts  the  distribution  to 
within  the  government,  thereby  keeping  a large  portion  of  the  total  team 
uninformed.  Specifically,  by  combining  the  planning  function  data  with  all 
of  the  control  function  data,  the  entire  industrial  base  is  prohibited 
from  seeing  the  overall  scope  and  details  of  the  plan.  If  the  planning 
function  data  and  schedule  data  were  published  as  single  volune,  this 
oould  not  only  be  given  to  interested  potential  contractors  but  it  would 
even  be  possible  to  ask  for  contractual  support  in  developing  this 
critical  portion  of  the  PMP. 

Whether  or  not  the  manpov^r  and  organization  data  is  published  sep- 
arately or  aonbined  with  the  budget  and  cost  estimate  data  is  not  as 
critical  as  tlie  separation  of  the  planning  function  data  from  the  control 
function  data.  The  separation  of  these  dat-*  should  be  considered  as 
appropriate  for  each  program  after  an  estimate  is  made  regarding  the 
frequency  of  update  and  total  volune  of  data  required  in  each  of  these 


Assuming  that  the  PMP  of  a given  program  will  be  published  in  more 
than  one  volune  and  using  AFSCP  800-3  (l:A4-l),  as  a model,  the  follow- 
ing topics  oould  be  assigned  to  each  of  three  proposed  volumes. 

\tolune  I - Program  Plan,  Schedules  and  Milestones. 

This  volune  should  address  all  topics  except 
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those  identified  in  Section  3e,  Financial;  Section 
3f , Procurement  Strategy;  Section  11,  Manpower  and 
Organization;  and  Section  12,  Personnel  Training. 

Volume  II  - Budgets  and  Fiscal  Plans 

This  volune  should  address  Section  3e  and  Section 
3f,  including  the  detailed  rationale  for  the  fiscal 
data.  This  volune  would  also  include  cost  estimate 
date. 

Volume  III  - Manpower  and  Organization 

Sections  11  and  12  should  be  detailed  in  this 
volume. 

The  PMP  development  process  is  simmarized  in  Figure  1. 

The  next  logical  question  is  "why  must  the  initial  PMP  be  so  exten- 
sive and  detailed?"  The  answer  is  that  the  PM  must  understand  the  nature 
and  nunber  of  subsequent  documents  which  are  dependent  upon  the  PMP.  We 
have  alluded  to  seme,  the  budget,  the  APP  and  the  DCP.  Unfortunately 
there  are  many  more,  some  of  which  are  part  of  a docunent  chain  having 
broad  iitpacts,  especially  if  the  PMP  is  for  a large  major  weapon  system. 
Figure  2 graphically  depicts  sate  of  the  major  documents  and  subsequent 
iiqpacts  the  PMP  has  on  other  planning  documents.  Although  the  dependent 
documents  identified  in  Figure  2 cure  not  all  inclusive  of  the  various 
places  where  the  PMP  information  is  required,  it  does  answer  the  question 
of  why  the  initial  PMP  must  be  as  extensive  and  precise  as  possible  when 
it  is  published.  Changes  to  the  information  within  the  published  PMP  often 
cause  significant  impacts  throughout  the  DOD  and  Congressional  fiscal 
aoranittees.  When  these  type  changes  occur,  the  program  manager  spends  a 
very  significant  amount  of  time  answering  the  flood  of  questions  and 
criticism  from  the  various  agencies  which  are  dependent  upon  that  PMP 
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information.  Once  a program  is  initiated,  there  is  no  doubt  that  all  of 
the  information  which  should  be  in  the  initial  FMP  will  be  addressed  - 
either  yyy><*t  or  later.  If  the  chosen  time  is  later,  the  PM  will  pay  a 
severe  price  in  time  fcy  simply  trying  to  research  and  answer  the  inevitable 
questions  one  at  a time.  Yes,  the  initial  PMP  is  critical  and  has  far 
reaching  effects  throughout  all  of  DGD,  so  do  it  right  the  first  time  and 
help  yourself  Mr.  Program  Manager. 
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DE-OPTIMIZING  FACTORS 

In  the  previous  section  an  argument  has  been  developed  for  a logical, 
extensive  sequence  of  events  which  need  to  occur  to  produce  the  "ideal" 
PK*.  Recognizing  that  the  real  working  environment  is  a significant 
deviation  from  the  ideal  model,  it  is  as  important  for  the  PM  to  under- 
stand those  major  factors  which  work  against  the  ideal  model  as  it  is  for 
him  to  understand  the  model  itself.  Hopefully,  the  PM  who  has  knowledge 
of  both  the  model  and  the  factors  which  tend  to  resist  his  efforts  to 
produce  his  PMP  can  make  reasonable  conscious  trade  offs  in  the  process 
rather  than  proceeding  into  trouble  through  ignorance.  It  is  the  objec- 
tive of  this  section  to  discuss  some  of  these  major  factors. 

Faced  with  an  accusation  that  the  initial  PMP  was  inadequately 

prepared,  PMs  offer  a wide  variety  of  reasons  for  the  deficient  docvxnent. 

Although  not  an  exhaustive  list,  the  following  factors  are  the  most  cannon 

reasons  offered. 

. Inside-Out  Approach 
. Preconceived  Solution 
. "My  Plan"  Syndrome 
. Inadequate  Threat  Definition 
. Inadequate  Technical  Base 
. Inadequate  Staff  Support 
. Time  Pressure 
. Wrong  Priority 

Many  of  these  factors  are  often  found  combined  in  any  given  situation. 
In  fact,  any  or  all  of  these  factors  may  be  present  during  the  initiation 
of  a new  program.  It  is  necessary  for  the  PM  to  recognize  than  and 
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have  techniques  to  cope  with  the  problems  they  cause.  Lets  examine  each 
one  individually. 

Inside-Out  Approach 

This  is  undoubtedly  the  most  frequent  cause  of  bad  PMPs.  This  pro- 
cedure is  to  start  with  a given  set  of  control  elements  and  an  assured 
threat  and  try  to  build  a plan  to  fit  it.  The  starting  point  is  always 
the  same  - a directive  from  higher  authority  which  appoints  a PM  or  task 
force  leader,  gives  him  a directive  to  set  up  an  offioe  and  develop  a PMP 
which  will  deliver  a new  military  widget  for  field  deployment  in  five 
years.  The  PMP  is  due  in  ninety  days  and  you  are  authorized  five  people 
and  $250,000  for  this  first  fiscal  year.  And  "Oh,  by  the  way,”  the  total 
aost  should  be  about  "n"  millions  of  dollars.  At  this  point,  the  PM  goes 
back  to  Headquarters  and  pleads  his  case  for  not  being  able  to  do  that. 
Headquarters  acknowledges  that  may  be  true  but  wants  him  to  try  anyway. 
The  military  "can-do"  attitude  takes  over  and  the  PM  mashes  together  a 
PIP  which  meets  all  of  the  initial  requirements.  Since  only  the  PM  has 
to  approve  the  PMP,  he  does  not  have  to  tell  anybody  that  the  schedule  is 
impossible,  the  plan  is  poorly  conceived  and  the  estimated  cost  is  a 
factor  of  four  too  low.  He  ocnplied  with  the  directive  and  he  can  always 
correct  the  plan  later  when  he  has  time  to  think  about  it  a little  more. 
Mo  wonder  the  program  has  schedule  slips  and  cost  overruns.  There  never 
wss  s bottoms  up  look  at  this  PMP.  It  was  doomed  with  the  initial  edict 


Preconceived  Solution 


One  of  the  most  dangerous  approaches  to  the  development  of  the  PMP 


is  where  the  solution  is  preconceived.  In  this  case,  alternatives  are 
rarely  developed  and  since  the  path  is  already  "known,"  schedules  and 
resources  will  invariably  be  badly  biased  on  the  optimistic  side.  When 
difficulties  develop  in  the  program,  there  is  either  a mad  scramble  to 
develop  an  alternative  fix  or  more  likely,  the  PM  will  insist  that  with 
more  resources  and  time  he  will  overcame.  Such  plans  are  always  premised 
upon  100%  success  and  decision  points  are  not  easily  identified  nor 
objectively  evaluated.  Preconceived  solution  FMPs  must  be  avoided  if 
cost  and  performance  trade  offs  are  a viable  tenant  of  the  weapons  acqui- 
sition business. 

My  Plan  Syndrome 

Deeply  imbedded  in  the  "Program  Manager"  philosophy  is  the  charter  of 
PM  independence  regarding  how  he  runs  his  program.  Sane  PMs  interpret  this 
to  mean  total  autonomy  within  their  program,  including  the  development  and 
publication  of  the  PMP.  The  Air  Force  guidance,  AFSCP  800-3,  Attachment  4, 
dated  9 April  1976,  further  encourages  this  by  implying  that  the  final 
approval  authority  for  the  PMP  is  the  PM  himself.  Furthermore,  AFSCP  800-3 
clearly  states  that  its  contents  are  not  directive  upon  the  PM  but  are  to 
be  used  as  guidance  in  the  development  of  the  PMP.  Fortified  with  this 
new  found  authority,  some  PMs  develop  the  philosophy  that  the  PMP  is  "ny 
plan"  and  its  nobody  else's  business  how  I run  ny  program.  Subsequently, 
the  PM  is  forced  at  least  to  demonstrate  that  he  has  a master  plan,  so  he 
submits  a plan  with  only  enough  information  in  it  to  get  the  inquirer  off 
his  back.  When  queried  further  about  the  skimpiness  of  the  PMP,  the  PM 
often  raplys,  "The  less  I tell  them,  the  less  they  try  to  run  ny  program." 
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MtLle  his  intent  is  to  prevent  higher  authority  from  managing  his  pro- 
gram, by  witholding  information  he  is  also  depriving  his  team  members  of 
the  very  information  they  need  to  support  his  program.  This  approach 
creates  unnecessary  management  difficulties  and  usually  results  in  a poor 
product  or  no  product  at  all. 

Inadequate  Threat  Definition 

Theoretically,  a threat  is  a logically  concluded  definition  of  a 
proposed  military  capability  deficiency  which  is  forecast  for  seme  future 
date.  That  is,  starting  with  a set  of  facts  of  today  and  seme  historical 
trend  data,  an  analysis  and  forecast  of  a future  military  situation  is 
made  for  acme  finite  time  into  the  future  and  an  assessment  made  as  to 
whether  or  not  the  United  States  Military  farces  will  be  adequate  to 
successfully  negate  the  proposed  situation.  If  the  conclusion  is  that 
Uiited  States  forces  will  not  successfully  negate  the  situation,  a threat 
i or  military  deficiency  is  documented  and  presented  to  the  Joint  Chiefs  of 
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Staff  (JCS)  for  consideration.  In  this  process  it  is  not  unoenmon  for 
each  analyst  and/or  organization  to  make  different  assumptions  and  arrive 
at  vastly  different  conclusions . If  the  deficiency  is  validated  by  the 
JCS  the  usual  reocRmendaticn  is  to  develop  and  deploy  a new  weapon  system. 

I ' A more  likely  situation  however  is  for  a case  to  be  presented  that 

suggests  a given  weapon  system  is  or  has  beoome  obsolete  and  needs  to  be 
replaced  with  a bigger  and  better  system.  This,  of  course,  is  the  signal 
for  a new  system  proponents  to  cause  a new  threat  to  be  defined  to 
justify  the  bigger  and  better  system.  Occasionally,  a new  technology 
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development  will  result  in  a solution  and  90  looking  for  a problem.  In 
this  case,  the  results  are  the  same  as  the  obsolescent  case  - a deficiency 
is  defined  to  meet  the  new  solution. 

Kell,  so  what?  Does  it  really  make  any  differences  how  the  threat 
stud/  got  initiated?  Probably  the  answer  to  that  is  no.  Fran  the  new 
PMs  point  of  view  it  really  makes  little  difference,  until  he  tries  to 
define  a plan  for  solving  this  new  threat.  Now  it  becomes  most  critical 
for  him  to  clearly  understand  the  basis  for  the  threat  analysis  and 
aaam|i  Lions  for  he  trust  make  sure  that  his  new  weapon  system  will  do  the 
job.  Unless  he  fully  understands  the  facts  and  assumptions  of  this  threat, 

9 

it  is  iapossible  for  him  too  do  any  contingency  planning  to  aoooqmodate  the 
change  in  threat  which  will  inevitably  occur  during  the  development  too 
deployment  lifetime.  ' 

The  new  PM  is  usually  hesitant  to  challenge  the  threat  at  this  early 
stage  so  he  assumes  the  threat,  is  valid  and  sets  about  developing  his  PMP 
with  great  haste  in  order  to  get  this  new  program  underway  "as  soon  as 
possible."  The  minute  this  PM  signs  off  on  this  threat  definition  he  has 
just  made  a basic  assumption  which  new  becomes  associated  with  him  and 
not  the  analysis  organization  who  suddenly  retreats  to  the  supportive 
sole.  Mien  this  happens,  the  PM  has  just  passed  the  first  road  sign 
pointed  toward  trouble. 

Inadequate  Technical  Base 

Rarely  are  errors  about  the  actual  status  of  the  technical  base 
fatal  to  a program.  In  most  cases  *the  PM  suddenly  inherits  a much  more 
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extensive  development  program  than  he  anticipated  with  the  usual  conse- 
quences of  schedule  slips  and  program  cost  growth.  Occasionally,  the 
technical  base  is  so  badly  over  estimated  though  that  the  entire  program 
mist  be  either  terminated  at  a later  date  or  the  system  developed  through 
the  validation  phase  and  shelved  since  another  weapon  system  has  been 
chosen  to  meet  the  threat. 

Technical  risk  is  one  of  the  problem  areas  that  the  IM 
expects  to  handle  throughout  the  entire  development  process.  But  the 
manager  who  develops  a plan  with  serious  errors  in  his  technical  base 
assumptions  has  just  asked  for  trouble  at  the  very  beginning. 

Inadequate  Staff  Support 

Oiite  often,  the  proposed  program  management  office  has  not  been 
officially  established  when  the  initial  PUP  is  being  developed.  A snail 
task  force  and  a PM  designee  or  task  force  leader  is  tasked  with  writing 
the  P».  If  this  task  force  insists  vpan  being  the  sole  source  of  knowl- 
edge in  the  development  of  the  PMP,  it  will  suffer  from  inadequate  staff 
support.  Ihe  team  in  charge  of  this  effort  has  an  obligation  to  identify 
and  use  all  of  the  expertise  available,  and  particularly  those  organiza- 
tions which  will  subsequently  be  involved  in  the  program.  For  example, 
all  functional  support  organizations  such  as  engineering,  safety,  pro- 
curement, intelligence  agencies,  user  command,  personnel  manpower  eval- 
uation teams,  and  even  potential  contractors  should  be  requested  or 
directed  to  help  develop  the  MP.  After  all,  if  these  organizations  are 
required  to  support  this  program,  they  have  a vested  interest  in  ensuring 


2t 


■ * 

I i 


i t 


that  goes  well  and  are  more  than  academically  interested  in  the  devel- 
opment of  this  PMP.  Furthermore,  if  these  organizations  are  involved  in 
the  development  of  the  initial  plan  they  beocne  quite  ocrmitted  to  the 
program  and  will  begin  to  support  it  with  considerably  more  enthusiasm 
than  they  will  if  asked  to  join  the  team  later  on.  PMP  docixnents  which 
are  bad  because  of  "inadequate  staff  support"  should  cause  higher  author- 
ities to  reconsider  very  carefully  before  keeping  these  same  task  force 
people  in  the  program  management  office. 
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Time  Pressure 

From  day  one,  the  PM  is  going  to  be  under  severe  time  pressures. 

These  pressures  come  from  every  direction  and  are  almost  invariably  caused 
by  an  assvnption  made  in  the  threat  definition  which  has  established  a 
very  arbitrary,  but  firm,  date  of  deployment  of  this  new  weapon  system. 

The  typical  PM  responds  to  this  urgency  pressure  by  reducing  the  time 
allocated  far  developing  the  PMP  to  as  near  zero  as  possible.  He  always 
intends  to  do  it  better  next  time  when  he  updates  it,  but  the  damage  is 
done.  It  has  been  published  and  acoepted  as  his  best  plan  the  minute  it 
leaves  his  desk.  The  worst  part  of  this  is  that  while  he  thinks  he  has 
saved  time  and  gotten  the  program  started  in  record  time,  he  finds  out 
very  soon  that  not  only  is  the  inadequate  planning  causing  him  to  have 
frequent  "surprises,"  but  he  is  actually  spending  a great  deal  of  his 
time  researching  and  answering  questions  which  should  have  been  in  the  PMP. 
Although  time  management  is  viewed  as  an  adnirable  virtue  for  a PM, 
cheating  himeelf  here  is  a costly  mistake. 


29 


331 & 


i 

t 


Wbong  Prioit^ 

Normally,  when  a PM  is  appointed  to  start  a new  program,  he  is 
immediately  flooded  with  a deluge  of  requests  for  budget,  manpower 
requests,  plans,  and  even  the  first  Decision  Coordinating  Paper  (DCP) . 
Amongst  all  this  confusion,  the  PM  is  very  likely  to  assign  work  prior- 
ities which  will  satisfy  the  most  people  in  the  very  near  term.  In  doing 
so,  the  PMP  is  often  assigned  far  less  than  the  number  1 priority  which 
it  so  desperately  needs  in  this  early  phase  of  the  program.  As  a result, 
budgets,  both  current  year  and  out  year,  organization  decisions,  manpower 
requests,  etc,  are  "tenporarily"  submitted  while  the  PMP  is  developed. 
Much  to  the  surprise  of  the  PM,  he  soon  finds  out  that  the  "temporary" 
submissions  have  shown  up  in  many  of  the  documents  illustrated  in  Figure 
2.  Thus,  a new,  unexpected  problem  now  exist  - getting  those  numbers 
changed  - which  requires  the  talents  of  the  very  people  trying  to  develop 
the  PMP.  Finding  himself  in  this  vicious  circle,  the  PM  may  never  re- 
cover enough  to  fully  develop  an  adequate  PMP  no  matter  how  hard  he  tries. 


Despite  all  of  the  de-optimizing  factors  which  exist,  with  sane  under- 
standing of  the  process  and  a few  changes  in  the  way  the  PM  develops  the 
IMP,  it  can  be  a good  plan  and  the  most  valuable  docunent  in  the  program 
management  office. 
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REDOMMENDATIONS 

Just  as  there  is  a truth  in  lending  1 aw  today  there  is  a very  strong 
trend  today  at  the  Congressional  and  the  OSD  level  to  have  truth  in  plan- 
ning for  new  weapons  systems  acquisitions.  It  is  an  interesting  fact  to 
notice  that  Congress  rarely,  if  ever,  has  refused  to  approve  a program 
start  because  of  initial  estimates  of  cost  or  schedule.  However,  Congress 
routinely  kills  programs  for  severly  overrunning  the  initial  estimates  of 
cost  and  schedule. 

Well,  how  do  we  reverse  this  trend  then  of  publishing  "bad"  PMPs, 
the  initial  source  of  all  of  this  data?  The  answer  is  neither  clear  nor 
simple,  but  severed  simple  changes  could  make  a big  step  in  the  right 
direction.  The  results  will  neither  be  instantaneous  nor  dramatic,  but 
failure  to  consider  changing  is  to  ignore  the  problem. 

The  first  reoanmendation  is  to  educate  the  FMs,  future  PMs  and  key 
Headquarters  personnel  in  the  importance  of  the  initial  PMP  and  the 
tremendous  impact  it  hats  on  all  subsequent  actions  which  will  effect  this 
program.  For  those  few  major  programs  it  may  even  be  appropriate  to  have 
the  PM  hear  that  message  loud  and  clear  from  the  Secretary  of  Defense 
himself.  For  lesser  programs,  the  signatory  of  the  PM's  charter  may  be 
appropriate. 


Second,  Headquarters  must  stop  issuing  directives  which  result  in 
the  inside-out  development  of  the  PMP.  Specifically,  the  control 
factors  of  scheduling,  costing,  and  resource  allocation  should  not 
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even  be  considered  until  the  programmed  plan  is  completed  and 
reviewed.  When  the  proposed  team  members  have  approved  this  portion  of 
the  PMP  then  the  control  function  can  be  developed. 

Third,  authorities  above  the  PM  must  stop  managing  the  program  in  order 
to  eliminate  the  "My  Plan"  syndrome.  If  the  PM  is  expected  to  provide  the 
detailed  information  required  in  the  PMP  then  he  must  have  the  freedom  to 
use  the  document  in  his  way.  Tto  do  otherwise  will  result  in  the  PM 
withholding  information.  If  it  is  necessary  for  the  higher  authorities  to 
manage  the  program  then  they  should  change  PMs. 

Fourth,  the  PM  must  insist  that  adequate  time,  priority  and  resources 
are  made  available  for  him  to  properly  develop  the  initial  PMP.  Further- 
more, the  PM  must  make  maximum  use  of  all  potential  team  members , and  re- 
sources, including  industrial  organizations. 

Fifth,  the  format  of  the  PMP  should  be  in  three  volumes.  One  volune 
should  contain  all  the  rationale  and  data  to  support  a scheduled  plan-start 
to  finish.  A second  volume  should  address  only  oost  estimates  and  fiscal 
matters.  The  third  volume  should  address  the  organizational  and  manpower 
portion  of  the  plan,  including  interagency  relationships  and  planned 
memoranda  of  agreement.  By  publishing  it  in  three  volunes,  each  team 
member  can  be  provided  with  only  those  portions  which  are  necessary  for 
his  part  of  the  effort.  For  example,  industry  could  be  involved  in  the 
development  of  Volume  I,  the  Program  Plan,  Schedules  and  Milestones  since 
no  critical  cost  information  is  in  that  volune.  There  is  even  a chance 
that  a more  reasonable  and  attainable  plan  and  schedule  could  be  developed 
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with  industrial  participation.  Hopefully,  industrial  markers  of  the 
team  would  also  plan  their  efforts  better,  resulting  in  a more  efficient 
program  overall,  if  they  were  involved  in  the  development  of  this  part 
of  the  program. 

1 

. 

Finally  the  PM  must  quit  blatantly  accepting  the  given  threat  and 
• seriously  challenge  the  user's  view  of  the  threat  definition.  He  must 

understand  the  assumptions  and  reality  of  the  military  deficiency  he  is 
going  to  try  to  solve  before  he  develops  his  plan. 
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SMART 

In  the  introduction,  the  hypothesis  was  made  that  the  development  of 
the  initial  Program  Management  Plan  is  the  most  critical  effort  in  the 
life  cycle  of  a new  weapon  system.  During  the  background  discussion,  the 
point  was  made  that  since  1961,  the  entire  Department  of  Defense  has  been 
undergoing  a radical  and  traumatic  evolution  in  the  manner  in  which  the 
military  ccnplex  develops  and  acquires  new  weapon  systems.  The  point  was 
made  that  mistakes  are  inevitable  throughout  this  evolution  and  criticism 
will  be  severe. 


it  . 


Against  this  background  then,  the  PMP  formulation  discussion  centered 
around  a PMP  development  process  model  which  is  analogous  to  the  PPBS 
logic.  Specifically,  the  model  proposes  that  the  PMP  should  be  developed 
in  discrete  and  finite  operations  which  permit  each  subsequent  operation 
to  be  based  upon  the  ccnposite  of  information  developed  in  previous  opera- 
tions. The  PMP  model  was  defined  as  being  composed  of  two  functions, 
planning  and  control.  The  planning  function  consists  of  three  elements, 
defining  the  basic  assumptions,  option  planning  and  programing  the 
planned  options.  The  control  function  consists  of  three  elements,  sched- 
uling, costing  and  resource  allocations . The  sequential  and  dependency 
hierarchy  of  these  functions  and  elements  are  discussed  and  graphically 
displayed  in  Figures  1 and  2. 

The  PMP  formulation  section  ends  with  a discussion  of  formating  the 
PUP  into  three  volumes;  Volume  I,  Program  Plan,  Schedules  and  Milestones; 
Volume  II,  ftidgets  and  Fiscal  Plans;  Volume  III,  Manpower  and  Organizations. 
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Arguments  are  presented  for  this  format  which  propose  that  increased 
utility  within  the  participating  industrial  ocnplex  requires  that  Vblune 
I of  the  PMP  be  made  available  to  them. 

The  next  section,  De-Optiznizing  Factors,  discussed  eight  major 

factors  which  current  PMs  have  experienced  which  provide  strong  forces  to 

develop  the  PMP  in  a less  than  optimum  manner.  These  eight  factors  were 

. Inside-Out  Approach 
. Preconceived  Solution 
. "My  Plan"  Syndrome 
. Inadequate  Threat  Definition 
. Inadequate  Technical  Base 
. Inadequate  Staff  Support 
. Time  Pressure 
. Wrong  Priority 

Finally,  six  reocnmendations  are  made  which  could  have  long  range 
and  lasting  impacts  vpcn  the  quality  of  the  initial  PMP  and  subsequent 
program  efficiency.  These  were,  PM  education  regarding  the  critical 
nature  of  the  initial  PMP,  oessation  of  Headquarters  dictating  the  con- 
trol factors  prematurely  in  the  program,  less  Headquarters  program  man- 
aging based  upon  details  disclosed  in  the  PMP,  PM  insistence  upon  adequate 
time  and  resources  to  develop  the  initial  PMP,  the  re  formating  of  the 
PM*  into  three  volumes  to  provide  increased  utility  of  the  dociront,  and 
finally,  the  PM  must  seriously  critique  the  user's  threat  assunptions 
and  definition. 
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APPENDIX  I 

HOW  TO  PREPARE  THE  PROGRAM  MANAGEMENT  PLAN 


1.  Criteria.  This  attachment  provides  criteria  that 
riiould  be  considered  for  each  section  of  the  PMP. 
The  material  presented  is  for  information  and  guid- 
ance and  is  not  directive.  The  Program  Manager 
should  issue  specific  instructions  and  format.  A sec- 
tion distribution  list  should  be  made  if  different  from 
the  PMP  master  distribution  list. 

2.  Program  Summary  and  Authorization  (Section  1). 

a.  Briefly  describe  the  system/equipment  and  the 
acquisition/management  approach  as  required  to  en- 
sure participating  organizations  and  management  of- 
ficials understand  the  key  features  of  the  program.  It 
should  also  summarize  the  research  and  development 
background  and  the  rationale  for  the  equipment/sys- 
tem selected  (reference  the  Development  Concept 
Paper  if  applicable). 

b.  Include  a summary  or  reference  to  latest  issues 
of  program  directive  documents  (PMDs,  AFSC  Form 
S6,  and  so  forth)  that  establish  program  parameters, 
identify  resources,  and  otherwise  govern  the  con- 
tinued actions  of  participating  organizations.  It  will 
also  include  the  importance  categoiy,  precedence 
rating,  and  program  priority,  if  assigned. 

3.  Intelligence  (Section  2).  The  product  division  in- 
telligence office  is  responsible  for  providing  a single 
point  of  contact  for  intelligence  information  and 
support  to  the  PO.  The  content  of  this  section  should 
be  limited  to: 

a.  Identification  of  the  Threat.  This  part  should 
consist  of  a listing  of  all  threats  relevant  to  the 
program.  It  should  only  include  sufficient  data  to 
properly  identify  each  threat  system;  it  should  not 
include  a narrative  or  descriptive  information  such  as 
performance  parameters  and  system  characteristics. 

b.  Identification  of  Relevant  Foreign  Tech- 
nologies. This  part  should  list  categories  of  tech- 
nologies that  are  significant  to  the  program;  it  should 
be  very  brief.  The  purpose  is  to  identify  those 
categories  of  foreign  technology  data  which  may 
prove  to  be  valuable. 

c.  Documentation  of  Intelligence  Require- 
ments. This  part  should  define  the  level  of  detail  and 
kind  of  data  required  on  those  threat  tystems/tech- 
oology  categories  identified  in  parts  a and  b.  It  should 
also  define  specific  or  unusual  intelligence  support 
which  may  be  required,  such  as:  full-time  intelligence 
officer  support  from  the  local  intelligence  office; 
threat  working  group  support;  special  studies  support 
and  threat  scenario  requirements. 

d.  Reference  Intelligence  Documents.  This  part 


should  reference  DIA,  FTD,  using  command,  or  other 
intelligence  documents  that  supply  data  critical  to  the 
program  efforts,  and  reference  documents  which  im- 
pact threat  identification. 

e.  Threat  packages  or  summaries  should  be  pub- 
lished separate  from  the  PMP. 

4.  Program  Management  (Section  3).  This  section 
should  provide  a description  of  the  overall  manage- 
ment concept  and  approach,  in  somewhat  more  detail 
than  that  in  section  1,  which  will  be  used  to  meet  the 
requirements  of  the  program.  The  methods  employed 
will  ensure  sufficient  real-time  visibility  concerning 
contractor  effort  to  allow  a continuous  assessment  of 
program  progress  and  technical  performance, 
schedule  and  costs;  that  is,  an  integrated  management 
information  system  tailored  to  program  office  and 
contractor  needs.  The  following  major  subsections 
should  be  addressed  for  each  program: 

a.  Technical  Performance.  Develop  a management 
approach  that  will  provide  for  continuous  assessment 
of  program  accomplishments  versus  stated  require- 
ments. 

b.  Schedules.  Participating  organizations  should  as- 
sist in  preparing  AFSC  Forms  103,  Program  Schedule, 
to  show  a master  schedule  of  major  milestones,  key 
events,  and  any  critical  actions  essential  to  timely 
execution  of  the  program.  Detailed  schedules  should 
also  be  included  in  this  section  such  as: 

(1)  Muter  Program/Overall  Milestone  Schedule 

(2)  Production/Delivery  Schedules. 

(3)  Facilities  and  Site  Activation  Schedules. 

(4)  Action  Schedules. 

(5)  Tut  Schedules. 

(6)  Training  Schedulu. 

The  Program  Manager  should  ensure  that  the 
scheduled  activities  of  participating  organizations  are 
compatible  and  consistent  with  the  program  sched- 
ulu. 

c.  Interrelationships.  Define  the  interrelationship 
of  major  commands  and  other  Government  and  non- 
Goverament  organizations  that  will  provide  major 
support  to  the  program.  Reference  should  be  made  to 
written  agreements  with  participating  organizations. 
Describe  the  us  of  any  independent  assessment 
teams  at  selected  key  mitestonu  in  the  program. 
Iiu'ude  interrelationships  among  or  between  AFSC 
field  commands  and  laboratoriu. 

d.  Reporting  Requirements.  Identify  reports  to  be 
submitted  to  meet  the  requirements  of  higher  head- 
quarters and  other  participating  commands,  including 
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a cross-reference  with  the  applicable  directive.  Also, 
indicate  whether  contractor  inputs  will  be  required. 

e.  Financial.  Include  a summary  of  the  total  costs 
of  the  program  including  costs  of  acquisition,  logistic 
support,  related  military  construction  and  operation 
by  the  operating  command.  The  Program  Manager  is 
responsible  for  the  overall  development,  collection, 
analysis,  and  presentation  of  financial  data  for  a PMP. 
The  participating  and  support  commands  are  the 
source  of  financial  estimates  for  their  areas  of  respon- 
sibility, and  normally  furnish  the  program  office  cost 
data  and  information  on  the  methods,  techniques, 
and  factors  used  in  developing  their  estimates.  Sum- 
maries should  be  in  tabular  format  including  prior 
fiscal  years,  current  fiscal  year,  S succeeding  fiscal 
years,  and  to  completion.  Summary  data  should  be 
shown  for  the  following  appropriations  as  applicable: 

3010- Aircraft  Procurement 
3020-Missile  Procurement 
3080-Other  Procurement 
3300-Military  Construction 
3400-Operations  and  Maintenance 
3600-RDT&E 

Separate  entries  should  be  made  under  each  appro- 
priation to  identify  the  amounts  to  be  -budgeted  and 
managed  by  the  various  participating  commands.  For 
example,  in  3010.  an  AFSC  and  an  AFLC  amount 
would  normally  be  shown.  Entries  should  be  at  the 
Budget  Program  levels  only  for  each  appropriation; 
that  is,  3010-100000, 3020-210000, 3080-840000.  In 
3400,  a training  command  and  an  operating  com- 
mand amount  would  normally  be  shown.  In  updating 
the  financial  summary  information,  current  and  prior 
fiscal  year  entries  must  agree  with  program  direction 
and  the  USAF  F&FP.  Out-year  values  should  corre- 
spond to  the  latest  program  budget  submission  or 
SAR. 

f.  Procurement: 

(1)  Summarize  the  procurement  concept,  types 
of  contracts,  and  major  contractual  features  to  be 
used  on  the  program.  Include  aspects  of  documents 
that  establish  procurement  authority  and  otherwise 
govern  the  actions  of  participating  procurement  and 
production  activities.  Specifically,  include  aspects  of 
the  D&F,  the  Advanced  Procurement  Plan  and  subse- 
quent changes. 

(2)  Summarize  the  requirements  for  industrial 
facilities,  the  use  of  existing  Government  facilities 
aid  the  planned  use  of  Government-furnished  equip- 
ment, property,  and  services  in  the  program. 

g.  Production.  Summarize  aspects  of  the  Produc- 
tion Plan  including  the  planning  and  procedures  for 
integrating  production  management  and  engineering 
throughout  development.  This  discussion  should  iden- 
tify major  production  risks,  their  potential  impact, 
planned  resolutions,  and  the  approadi  to  proofing  of 
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critical  production  processes  and  equipment.  Prepara- 
tion for  the  production  decision  and  the  application 
of  Production  Readiness  Review  actions  before 
DSARC  milestone  III  should  also  be  discussed. 
Gearty  explain  the  measures  for  efficient  transition 
through  development  to  production  including  organi- 
zational readjustments  within  the  program  office.  The 
measures  implemented  or  planned  to  ensure  effective 
program  office/administrative  contracting  office 
(AFPRO,  DCASO,  NAVPRO)  relationships  and  Gov- 
ernment/contractor involvement  in  sufficient  depth 
for  efficiently  monitoring  the  production  phase 
should  be  portrayed. 

h.  Contractor  Data.  Summarize  the  major  data  re- 
quirements and  concepts  of  data  management,  includ- 
ing technical  publication  management  and  acquisi- 
tion. 

i.  Turnover  and  Transfer.  Describe  the  approach 
for  accomplishing  turnover  and  transfer  of  the  pro- 
gram to  the  operating  and  logistics  organizations. 

j.  Risk  Analysis.  Summarize  the  approach  for 
maintaining  a continuous  program  of  review  and 
analysis  to  identify  and  evaluate  program  risks  in  the 
areas  of  technical  performance,  schedule,  costs,  oper- 
ational risks,  and  their  interrelationships. 

k.  Information.  Identify  the  relationship  between 
information  officers  and  program  officials.  It  should 
also  cover: 

(1)  General  Policy.  Include  guidance  on  release 
of  information,  internally  and  externally,  through  all 
media;  that  is,  news  releases,  articles,  speeches, 
symposia,  technical  papers,  response  to  news  media 
queries,  and  photographic  and  audio  information 
materials. 

(2)  Information  Responsibilities.  List  Govern- 
ment and  contractor  organizations  and  their  responsi- 
bilities for  information  actions  regarding 
coordination,  clearance,  and  release  requirements. 
Provide  for  compiling  current  releasable  information 
on  major  aspects  of  the  program.  This  guidance 
should  be  made  available  to  all  Air  Force  and  contrac- 
tor offices  that  would  be  expected  to  provide  infor- 
mation to  the  public  on  the  program  either 
responding  to  queries  or  through  voluntary  release  in 
any  form.  Especially  important  is  information  pro- 
vided in  Congressional  statements  and  published  testi- 
mony before  Congressional  committees.  This  is  a 
primary  source  of  new  public  information  on  pro- 
grams. 

(3)  Security  Review.  Cross-reference  the  security 
section  in  providing  instructions  for  processing  ma- 
terials proposed  for  clearance  and  public  release. 

l.  Miscellaneous.  All  other  pertinent  program  man- 
agement information. 

5.  System  Engineering  and  Configuration  Manage- 
ment (Section  4).  This  section  should  provide  a 
description  of  the  overall  approach  to  be  taken  in 


38 


AFSCP  800-3  Attachment  4 9 April  197* 


( 


( 


f 


system  engineering  and  configuration  management. 

a.  System  Engineering  Management.  Describe  the 
program  effort  for  defining  the  preferred  system 
configuration  (system  definition),  engineering/tech- 
nical management,  and  the  integration  of  engineering 
disciplines  and  specialty  programs.  Provide  a brief 
description  of  the  major  equipment,  subtystem  and 
critical  items  with  the  engineering  design  approach 
for  acquisition.  Include  summaries  or  plans  for  risk 
reduction  programs,  technical  reviews,  and  studies 
nd  analyses,  particularly  life  cycle  cost  analyses,  if 
appropriate.  Major  equipment  and  subsystems  should 
be  identified  in  a manner  consistent  with  MIL-STD- 
881  to  ensure  uniformity  in  comparison  of  accom- 
plishment and  planning  and  for  follow-on  reporting 
or  necessary  revision  or  updating.  Summarize  the 
planned  approach  for  engineering  and  engineering 
management,  including  but  not  limited  to  the  follow- 

far- 

(1)  Engineering  definition  of  the  complete  sys- 
tem. 

(2)  Reliability,  maintainability,  nondestructive 
inspection,  corrosion  prevention,  human  engineering, 
survivability,  vulnerability  (including  electronic  war- 
fare considerations),  transportability,  value  engineer- 
ing, quality  assurance,  producibility,  technical  perfor- 
mance measurement,  and  defense  standardization 
program. 

(3)  Electromagnetic  compatability  and 
TEMPEST  aspects  of  electronic  and  electrical  equip- 
ment, including  analysis,  measurements,  standards, 
frequency  allocations  and  operational  constraints. 

(4)  Computer,  computer  programs,  and  associ- 
ated documentation  to  be  used  as  part  of  the  system 
or  equipment  and  that  necessary  for  support.  Con- 
siderations such  as  capacity,  environmental  compata- 
bility, and  requirements  for  functioning  with  other 
systems  should  be  included. 

(5)  Briefly  describe  the  approach  in  achieving  a 
total  system  safety  program  (flight,  ground,  environ- 
mental, radiological,  explosive,  and  nuclear).  Include 
determination  and  identification  of  standardized 
system  safety  engineering  tasks  prescribed  in  MIL- 
STD-882  as  applicable,  and  indicate  whether  the 
performance  of  these  tasks  is  planned  as  contractor 
or  in-house  effort.  Also  state  intentions  regarding  the 
information  and  operation  of  a System  Safety  Group 
(AFR  127-8). 

(6)  Evaluation  of  the  natural  aerospace  environ- 
mental factors  and  the  system’s  effects  upon  man’s 
environment. 

(7)  Human  factors,  to  include  personnel  planning 
information  and  training  requirements. 

(8)  Aircraft  Structural  integrity  Program  (ASIP). 

(9)  Biomedical.  The  assistance  of  specialized 
aerospace  medical  personnel  of  AFSC,  the  operating 
and  the  support  organizations  should  be  used  to 
identify  and  review  biomedical  apseett  of  the 
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man-machine  relationship.  Include  known  and  po- 
tential biomedical  problems  that  may  be  encountered 
during  acquisition  or  operational  use  of  the  system. 

(10)  Use  of  standard  or  currently  available 
mobility  shelters.  Consult  with  the  Air  Force  Wea- 
pons Laboratory,  Civil  Engineering  Division,  in  plan- 
ning for  use  of  currently  available  standard  mobility 
shelters  or  in  developing  special  types. 

b.  Configuration  management: 

(1)  Describe  how  functions  of  configuration 
management  will  be  accomplished  through  implemen- 
tation of  selected  management  techniques. 

(2)  Describe  what  management  tools  will  be  used 
to  apply  the  fundamental  principles  of  configuration 
management. 

(a)  Identification. 

(b)  Change  control. 

(c)  Status  accounting. 

(3)  To  provide  a basis  for  evaluating  management 
effectiveness  and  to  assist  in  decisionmaking,  describe 
the  management  concepts  for  accomplishing  the  fol- 
lowing configuration  requirements: 

(a)  Organization  (including  configuration  con- 
trol board  activity). 

(b)  Uniform  specification  program. 

(c)  Interface  control. 

(d)  Configuration  Management  Plan. 

*.  Test  and  Evaluation  (Section  5): 

a.  This  section  should  include: 

(1)  The  test  management  concept  including  or- 
ganizational structure  and  responsibilities.  All  partici- 
pating organizations  should  be  identified. 

(2)  Critical  issues  and  areas  of  risk. 

(3)  Specific  test  objectives. 

(4)  Reporting  requirements. 

(5)  Any  contractor  or  non-AFSC  test  facility 
that  is  to  be  used  rather  than  a technically  equivalent 
AFSC  facility. 

b.  Test  plans  should  include: 

(1)  Objectives  and  approach  for  Development 
Test  and  Evaluation  (DT&E),  including  Initial  Opera- 
tional Test  and  Evaluation  (10T&E),  developed  in 
coordination  with  the  operating  and  supporting  com- 
mands. Include  refurbishment  plans  applicable  to  the 
test  resources  (example:  aircraft)  used  for  DT&E. 

(2)  Participation  in  OT&E  beyond  10T&E  in- 
cluding plans  for  engineering  support  carried  on 
through  initial  deployment  of  the  system  to  an 
operational  theater  or  base.  Include  plans  for  operat- 
ing and  supporting  command  participation  in  DT&E 
and  other  program  activities  as  mutually  determined. 

c.  Include  test  support  identified  by  organization 
(Government  and  contractor)  and  location  where 
possible.  These  requirements  should  be  identified 
with  the  applicable  phase  and  show  the  approximate 
beginning  and  ending  dates.  The  following  are  typical 
support  requirements: 
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(1)  The  technical  and  logistic  support  required  to 
support  the  test  program. 

(2)  Range  and  base  support  requirements  such  as 
data  processing,  aircraft,  instrumentation,  data  reduc- 
tion, telemetry,  maintenance  and  checkout  equip- 
ment, building/space.  Reference  section  6 for  com- 
munications/electronics test  support  requirements. 

(3)  AFSC/scientific/industrial  facilities  to  be 
used. 

» 

7.  Communications/Electronics  (Section  6): 

a.  In  this  section,  communications/electronics  re- 
quirements should  be  individually  identified  for: 

(1)  Program  management  (any  special  communi-' 
cations  requirements  of  the  Program  Manager/pro- 
gram office). 

(2)  Test  support. 

(3)  The  operational  system. 

b.  The  following  should  be  considered  for  each  of 
the  above  categories: 

(1)  Quantities  and  types  of  equipment  and/or 
capabilities  such  as  ground  radio,  radar,  telemetry, 
navigational  aids,  flight  facilities,  meteorological, 
crypto,  CCTV,  special  telephone  features  (call  direc- 
tor), public  address,  intercom,  facsimile,  tape  record- 
big,  teletype,  hot  lines,  special  circuits,  microwave, 
satellite,  mobile-portable  equipment  and  information 
on  similar  items  that  would  assist  in  support  planning. 

(2)  Locations  where  equipment/capabilities  are 
needed  and  time  phasing  information  or  required 
operational  dates  where  applicable. 

(3)  Radio  frequency  support  required  and  not 
already  approved  for  the  locations  involved. 

(4)  Communications  security  for  all  telecom- 
munications integral  to  Air  Force  weapons  systems  or 
telecommunications  that  support  their  RDTAE. 

t.  Operations  (Section  7).  This  section  requires  in- 
puts from  the  operating  command  and  should  expand 
the  operational  concept  for  the  use  of  the  system  or 
equipment  as  further  formulated  during  the  acquisi- 
tion cycle,  it  should  include  information  on  the  use 
and  identification  of  the  system  or  equipment  capa- 
bility it  will  replace  or  enhance.  Supporting  studies 
and  documents  should  be  cross-referenced.  It  should 
cover  the  following  topics  as  appropriate: 

a.  Mission. 

b.  Limitations. 

c.  Deployment/Operational  Plan,  including  ready 
dates.' 

d.  Command  and  control. 

a.  Readiness  (including  availability  and  reliability). 

f.  Operational  test  and  evaluation  plan  (including 
disposition  of  Test  Articles). 

g.  Unit  maintenance. 

h.  Supply  and  safety. 

i.  Mcteorological/environment. 

J.  Electronic  warfare. 
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k.  Organization  structure.  . 

l.  Transportation. 

m.  Personnel/manpower. 

n.  Training. 

o.  Facilities. 

p.  Penetration  Aids. 

q.  Special  weapons. 

r.  Related  training  and  operational  readiqess  train- 
ing. 

s.  Electromagnetic  compatibility/electromagnetic 
environment/site  surveys. 

t.  Life  support. 

9.  Civil  Engineering  (Section  8).  Where  appropriate, 
include  or  refer  to  a master  plan  prepared  for  each 
installation  or  subinstallation  that  outlines  the  pro- 
posed site  development  for  the  total  facilities  re- 
quired. Categorize  facilities  as  technical  support  real 
property  (TSRP)  or  nontechnical  support  real  prop- 
erty (NSRP). 

a.  Management. 

(1)  Indicate  responsibilities  and  procedures  for 
programming,  design,  construction,  maintenance  and 
acceptance,  and  transfer  to  the  operating  command 
of  real  property  required.  The  civil  engineer  is  re- 
sponsible for  all  actions  supporting  acquisition  pro- 
grams. 

(2)  Establish  procedures  and  responsibilities  for 
making  changes  to  these  facilities  before  and  after 
acceptance  by  the  operating  command.  These  respon- 
sibilities and  procedures  will  be  within  existing  laws 
and  directives,  many  of  which  are  peculiar  to  this 
functional  area. 

(3)  Commitments  for  use  of  Government-owned 
facilities  for  development  testing  should  not  be  in- 
cluded in  a contract  with  a weapon-system  contractor 
unless  the  required  changes  have  been  included  in  the 
construction  program. 

b.  Civil  engineering  development: 

(1)  Identify,  early  in  the  system  life  cycle,  the 
necessary  exploratory  and/or  advanced  development 
in  the  facilities  support  and  substitute  areas,  such  as 
mobility  shelters. 

(2)  List  all  such  development  being  programmed 
(or  done)  by  project  title,  number,  or  other  method 
of  identification.  The  date  of  development  and 
planned  completion  should  be  compatible  with  the 
requirements  of  the  program. 

c.  Summarize  facility  support  resources  and  Mili- 
tary Construction  Programs  (MCP)  project  require- 
ment data,  as  follows: 

(1)  Indicate  existing  facility  resources  that  are 
available  to  satisfy  support  requirements. 

(2)  Include  a listing  for  each  site  by  fiscal  year 
showing  the  TSRP  and  NSRP  (separately  identified) 
facility  deficiencies  for  which  new  construction/alter- 
nation/land  is  required  and  must  be  funded  in  the 
MCP  (budget).  Include  construction  category  code. 
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program  element  code,  and  estimated  scope  and  cost 
for  each  project. 

d.  When  AFSC  becomes  the  interim  owner  of  the 
real  property,  pending  installation  of  system  equip- 
ment, describe  how  real  property  maintenance  and 
operation  will  be  controlled  and  performed  between 
the  time  construction  is  completed  and  the  time  the 
system  is  transferred  to  the  operating  command. 

10.  Logistics  (Section  9).  This  section  requires  in- 
puts from  the  responsible  logistics  organization  and 
other  participating  agencies.  It  should  provide  a com- 
prehensive description  of  the  tailored  logistics  con- 
cepts for  the  program.  Include  considerations 
supporting  integrated  logistics  applicable  to  the  sys- 
tem/equipment  planning,  design,  development,  test 
demonstration,  and  operational  processes.  Include 
logistics  program  planning  aspects  related  to  other 
elements  of  the  PMP,  supporting  the  varied  elements 
of  reliability,  maintainability,  and  transportability. 
Include  aspects  related  to  test  equipment,  supply 
support,  transportation,  packaging  and  handling,  and 
technical  data  at  all  levels  of  logistic  support.  The 
Integrated  Logistic  Support  Plan  (ILSP)  and  its  re- 
lated management  information  system  should  be  con- 
sistent with  this  section. 

11.  Manpower  and  Organization  (Section  10).  De- 
scribe the  organization  of  the  program  office  and 
summarize  the  relationships  and  roles  of  other  Air 
Force  and  Government  agencies  involved  in  the  acqui- 
sition program  such  as  laboratories,  centers,  and 
system  engineering  and  technical  direction  organiza- 
tions. Reference  any  formal  agreements  with  partici- 
pating organizations.  The  determination  of  the  opera- 
tional sysiem/equipment  manpower  requirements  is  a 
joint  effort  of  the  program  office,  the  operating 
command,  other  participating  organizations,  and  the 
sysiem/equipment  contractors. 

a.  Include  rationale  derived  from  the  operation  and 
maintenance  concepts  and  design  parameters  from 
which  the  manpower  requirements  are  generated. 

b.  Project  the  requirements  for  officers  and  airmen 
(by  grade  and  AFSC)  and  civilian  totals,  by  fiscal  year 
phased  through  the  system/equipment  life  cycle- 

c.  Include  organization  charts  and  brief  func- 
tional statements  for  the  operating  command  units 
to  which  the  system/equipment  manpower  will  be 
allocated. 

12.  Personnel  Training  (Section  II).  This  section 
requires  inputs  from  Air  Training  Command,  operat- 
ing commands,  and  other  participating  organizations. 
Summarize  personnel  training  required  to  meet  sys- 
tem/equipment tesu  and  operational  and  support 
activities.  Cross-reference  the  summary  to  other  sec- 
tions, to  reflect  related  actions  and/or  authorizations. 
This  lection  should  include: 


a.  Requirements  for  trained  personnel  for  the 
system/equipment. 

b.  Types,  location,  and  key  dates  of  individual 
training  courses,  emphasizing  early  planning  for  train- 
ing courses. 

c.  Major  items  of  required  training  equipment,  and 
associated  aerospace  ground  equipment,  with  activa- 
tion schedules. 

d.  Major  facility  requirements  for  expansions  in- 
volved in  training,  with  activation  schedules. 

e.  Initial  and  replacement  training  loads  by  fiscal 
quarters,  projected  for  S years,  if  applicable. 

13.  Security  (Section  12). 

a.  Security  Support.  In  this  section,  the  following 
type  information  shqpld  be  included: 

(1)  Classification  guidance: 

(a)  Provide  security  classification  data  for  as- 
signing classification  categories  to  the  various  ele- 
ments of  the  system  in  sufficient  detail  to  ensure  the 
fulfillment  of  security  requirements  from  the  begin- 
ning of  the  program  life  cycle. 

(b)  Designate  the  activity  responsible  for  pre- 
paring: 

L Additional  detailed  security  classification 
guidance  for  the  system,  including  downgrading  and 
declassifying  schedules  based  on  events,  test/develop- 
ment phasing,  or  passage  of  time. 

2.  DD  Form  254,  Contract  Security  Gassifl- 
cation  Specification,  to  be  furnished  to  bidders  and 
contractors,  and  for  keeping  such  lists  current. 

(2)  Security  review  for  public  release  of  informa- 
tion. Provide  instructions  for  processing  requests  for 
public  release.  Distinguish  between  information  that 
may  be: 

(a)  Approved  for  release  by  a designated  ac- 
tivity within  the  command. 

(b)  Released  only  after  being  processed  by  the 
Office  of  the  Assistant  Secretary  of  Defense  (Public 
Affairs). 

(3)  Release  of  information  to  foreign  nationals, 
foreign  governments,  and  international  organizations. 
Before  any  information  pertaining  to  the  program  is 
released  to  a foreign  national,  foreign  government  or 
international  organization,  the  program  manager  must 
obtain  foreign  disclosure  authority. 

(4)  Personnel  security  clearance  or  investigative 
requirements.  Allow  at  least  180  days  leadtime  for 
background  investigation,  and  60  days  leadtime  for 
National  Agency  Checks,  to  permit  required  investiga- 
tive actions  to  be  completed  before  access  to  classi- 
fied information. 

(5)  Industrial  security.  Include  a brief  outline  of 
the  specific  actions  required  to  fulfill  the  responsibili- 
ties for  industrial  security.  Give  attention  to  items 
such  as  the  development  of  special  security  require- 
ments, statements  of  intercommand  or  contractor 
agreements  to  be  effected,  and  whether  security 
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requirements  are  or  will  apply  to  industrial  facilities 
(contractors). 

b.  System  security.  An  objective  of  USAF  physical 
security  policy  as  related  to  development  and  acquisi- 
tion of  aerospace  systems  is  to  assure  the  concurrent 
development  of  system/equipment  defenses  against 
all  projected  forms  of  ground  threats,  overt  and 
covert.  This  section  should  include  information  con- 
cerning the  following  in  those  programs  where  system 
security  requirements  have  been  identified. 

(1)  Design  influence.  Briefly  describe: 

(a)  Physical  security  requirements  that  will  be 
incorporated  into  the  program  requirements  baseline 
and  technically  defined  in  the  system/equipment 
specification. 

(b)  Provisions  for  analyses  to  provide  system 
security  based  upon  the  vulnerability  of  the  system  in 
its  ground  based  operational  mode. 

(c)  Planned  analyses  that  should  provide  a basis 
for  trade  studies  between  system  design  and  security 
operational  procedures  to  select  the  design  approach 
for  implementing  the  operational  physical  security 
arrangement. 

(d)  Physical  security  vulnerabilities  that  will  be 
avoided  by  engineering  and  design  and/or  those  where 
action  will  be  taken  to  provide  effective  counter- 
measures. 

(2)  Operational  security  system  requirements: 

(a)  Countermeasures  proposed  in  response  to 
residual  vulnerabilities  not  amenable  to  correction  by 
the  engineering  and  design  process  should  be  iden- 
tified. Proposed  RAD  tasks  should  be  identified. 

(b)  Security  oriented  subsystem  configuration 


items;  for  example,  make  or  buy  security  hardware, 
software,  security  police  personnel  subsystem  require- 
ments, facilities,  and  logistic  support  together  with 
procedural  requirements  devised  specifically  to  en- 
hance the  physical  security  system  arrangement  that 
contribute  to  total  system  cost  and  operational  effec- 
tiveness should  be  identified. 

(c)  OPSEC.  Actions  taken  to  prevent  disclosure 
of  all  information  that  could  be  used  as  intelligence 
indicators  by  hostile  collectors  to  degrade  current  or 
future  activities  or  operations. 

(d)  COMSEC.  Include  degree  of  protection 
necessary  for  security  of  transmitted  data  and  type  of 
information  transmitted. 


14.  Application  of  Directives  (Section  13).  This  sec- 
tion should  consist  of  the  list  of  directives  selected  by 
the  Program  Manager  for  application,  wholly  or  in 
part,  to  the  program.  The  Program  Manager  should 
review  the  PMD  and  AFSC  Form  56  and  any  other 
special  considerations  in  determining  applicable  direc- 
tives. There  are  many  directives  that  may/re  quire 
action  by  the  program  office  in  managing  a program. 
The  Program  Manager  is  responsible  for  determining 
those  applying  to  his  program  and  requesting  waivers 
for  those  he  will  not  apply  when  the  directive 
applicability  is  not  optional.  Many  directives  have 
DOD  or  statutory  origins  and  cannot  be  waived 
within  the  Air  Force.  Before  approving  his  PMP,  the 
Program  Manager  should  ensure  that  requests  for 
waivers  are  submitted  through  the  appropriate  field 
command  OPR  channels  when  required. 
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